Multiple party on-line transactions

ABSTRACT

A role associated with one or more parties involved with a purchase transaction is received. A routing rule associated with the purchase transaction is also received, the routing rule defining how the purchase transaction is routed among the one or more parties. The purchase transaction is processed based on the role of each party and the routing rule.

TECHNICAL FIELD

This document relates generally to information management.

BACKGROUND

In the past sales at on-line retailers have surpassed the totals of theyear before. Computer users have become more and more comfortablereviewing products on the internet and having them delivered via mailorder. Often, such purchases are paid for using credit cards. Such anapproach may be convenient, such as when buying a large item from anestablished retailer. Other transactions lend themselves more towardon-line payment processing systems (which themselves may involve creditcard companies or by other mechanisms). For example, transactions may bepaid for through open payment systems such as Google Checkout or PayPal,such as when the person providing the product or service (the merchantor vendor) does not accept credit cards; or the buyer doesn't want toprovide credit card information directly to the merchant or vendor dueto lack of trust; or the buyer doesn't want to create an account at eachdifferent merchant or vendor. Other types of purchases may also becarried out using such payment systems.

More than one party can be associated with a purchase transaction. Forexample, a manager may be required to approve a purchase transaction ofan item that a salesperson wishes to purchase. In this case, the managermay have to purchase the item himself because the manager may not becapable of approving the purchase if the salesperson places the order.

SUMMARY

In general, one aspect of the subject matter described in thisspecification can be embodied in methods, systems and computer programproducts. One method includes the actions of receiving a role associatedwith one or more parties involved with a purchase transaction, receivinga routing rule associated with the purchase transaction, the routingrule defining how the purchase transaction is routed among the one ormore parties, and processing the purchase transaction based on the roleof each party and the routing rule.

Another aspect of the subject matter described in this specification canbe embodied in methods that include the actions of identifying one ormore parties associated with a purchase transaction in a virtualshopping cart; identifying one or more rules associated with thepurchase transaction and a role associated with each of the one or moreparties, determining whether to route the shopping cart to the one ormore parties based on the one or more rules and the role associated witheach of the one or more parties, and processing the shopping cart basedon the determination.

The details of one or more embodiments of the subject matter describedin this specification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a conceptual flow diagram of an example transaction processingsystem.

FIG. 2 is a block diagram of an example transaction processing systemfor processing a purchase transaction involving multiple parties.

FIG. 3 shows a graphical conceptual flow diagram of an example processfor processing a purchase transaction.

FIGS. 3A-3D show example screen shots associated with the conceptualflow diagram of FIG. 3.

FIG. 4 is a flow diagram of an example process for receiving informationassociated with a purchase transaction.

FIG. 5 is a flow chart of an example process for processing a purchasetransaction.

FIG. 6 is a flow chart of another example process for receivinginformation associated with a purchase transaction.

FIG. 7 is a flow chart showing an example processing of an on-linepayment transaction.

FIG. 8 shows an example of a generic computing device and a genericmobile device.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIG. 1 is a conceptual flow diagram of an example payment processingsystem 100. In general, the system 100 includes various computers102-108 (which may each be a single computer or a group of manycomputers such as an entire server farm or data center) that cancommunicate through a network 110 such as the internet. The computersinclude a seller system 102, such as that operated by a vendor who setsup and operates an on-line ecommerce web site. While reference is madeto various computers 102-108, other forms of electronic devicesincluding mobile communication devices, set-top devices, telephonydevices, portable devices and the like are possible.

The seller system 102 may create a web page and, as shown by Arrow A,register the seller with a payment server such as payment server 104.The seller may identify himself and herself, and may open an accountinto which payments from buyers may be placed. In addition, the sellermay optionally also open and populate an inventory database for goods tobe offered for sale by the seller. The seller in particular may identifynames and descriptions for items to be sold (which may include goods orservices), along with prices for the items.

As part of the registration process or at a later time, the paymentserver 104 may generate and provide mark-up code to the seller system(Arrow A) so that the seller can cut-and-paste the code into theseller's web page. The mark-up code may include HTML, XHTML code, orother forms of code for producing the display of a purchasing control,such as an “add to cart” button that causes payment server 104 to recordthat a visitor to the web site wants to add a particular item associatedwith the control to his or her cart.

As shown by Arrow B, the seller system 102 may then upload the completedweb page to a web page server 108, which may be, for example, a serveror servers at an internet service provider (ISP) with which the sellerhas a relationship, or may also be a server or servers owned andoperated by the seller.

At a later time, a user of a consumer system 106 may navigate to theseller's web page, such as by entering a search term for “hand-madejewelry” (which would be routed through a search server, not shown), andselecting a link for the relevant site from the provided search results.The user may navigate through the jewelry site and be provided withvarious web pages for the site, as shown by Arrow C.

At some point during this browsing process, the user sees something heor she likes either for himself/herself, for someone else, or even for abusiness transaction, and clicks on a control to purchase the item(e.g., add the item to his or her shopping cart). The control may be,for example, one of the controls generated by code provided by thepayment server 104 via Arrow A. Selection of the control may direct theuser's browser to obtain information from payment server 104 relating toa shopping cart to be associated with the consumer system 106. Forexample, as shown by Arrow D, the user may transmit informationidentifying his or her system and the control, and the payment server104 may use the information to determine the identity of the vendor, theitem selected, and the amount of the item, so as to update a shoppingcart for the consumer system 106. Alternatively, the information sent bythe consumer system 106 may include information identifying the vendorand the item and price, or the payment server 104 may acquire suchinformation from the web page server 108 or another source usingidentifying information submitted from the consumer system 106.

Once the payment server 104 has updated a shopping cart for the consumersystem 106 in its own records, it may pass information reflecting theupdated shopping cart back to the consumer system 106 (e.g., number ofitems in the cart and total dollar value of items in the cart), such asvia XML messaging, so that the consumer system 106 can display the cartto the user. The transmission of the information may occur in a mannerother than generating an entirely new web page for the consumer system106, so that the user need not have a new and separate browser windowopened or have their browser redirected to a site associated with thepayment server 104. The display of the new information may occur in thesame window or tab as the web page, such as by using an iframe or othersimilar structure. In general, the interaction with the payment server104 may occur in the background, unnoticed by the user.

Further interaction between consumer system 106 and payment server 104may occur in a similar manner or via redirection of an entire browserpane to the payment server 104. For example, the user may continue tobrowse the vendor web page for additional items (as indicated by ArrowC) and may have those items added to a shopping cart in a similarmanner. In addition, the user may browse to other vendor web sites andmay add items from those sites to their cart in a similar manner (e.g.,by selecting controls that those other vendors have obtained frompayment server 104, and that allow payment server 104 to identify theparticular items to be sold and the vendors of the items). Additionalactivity may occur via redirection, such as if the user chooses tocheckout and purchase all the items in his or her cart, as describedabove, and such action will involve additional transmissions asindicated by Arrow D.

In some implementations, a user can decide to involve more than oneparty in a purchase transaction. For example, a user may need to getsomeone's permission before purchasing an item. In another example, aparty may have to approve of the purchase for other reasons such asbudget or the other party is the one that will be paying for the item inthe purchase transaction (e.g., for example child needing authorizationfrom parent to purchase an item).

FIG. 2 is a block diagram of an example transaction processing system200 for processing a purchase transaction involving multiple parties.The transaction processing system 200 can, for example, be implementedin the seller system 102 or the consumer system 106 utilizing one ormore computing devices that include memory devices storing processinginstructions and processing devices for executing the processinginstructions. An example computing system is shown and described withreference to FIG. 8. Other implementations, however, can also be used.

The system 200 can allow for multiple parties to be involved in apurchase transaction. For example, when a user purchases an item onlineusing an on-line ecommerce website, the system 200 can route thepurchase transaction to one or more parties based on one or more rolesassociated with the party. The purchase transaction can then beprocessed based on the roles and the parties.

In one implementation, the transaction engine 202 can receive a role 204associated with one or more parties 206. The role 204 can define theresponsibility of each party 206 with regard to the purchase transaction208. Each of the parties 206 can, for example, participate in thepurchase transaction 208 before the purchase transaction 208 isprocessed for payment. The parties 206 can participate in the purchasetransaction 208 based on the role 204 of each party 206.

The role 204 can, for example, define the responsibility of each party206. The role 204 can for example, include any one of an approver, abuyer (or purchaser), a receiver, a suggestor or other roles. Anapprover can, for example, include any party that is in charge ofapproving the purchase transaction 208. For example, a manager may haveto approve a purchase transaction 208 of his or her employee. A buyercan, for example, include any party that is in charge of paying for thepurchase transaction 208. For example, a manager can be in charge ofpaying for the purchase transaction 208 of an employee. A receiver can,for example, include any party that receives the item or items in thepurchase transaction 208. For example, a gift can be purchased for afriend, and the friend can be indicated as the recipient, or receiver,of the purchase transaction 208. A suggestor can be any party that makesa suggestion to purchase a good or service, such as to a buyer.

In one implementation, each party 206 can be associated with one or moreroles 204. For example, the same party 206 can be in charge of bothapproving the purchase transaction 208 and receiving the items in thepurchase transaction 208. In other implementations, each role 204 can beassociated with more than one responsibility. For example, an approvercan be a party 206 that can approve of the purchase transaction 208 aswell as pay for the purchase transaction 208. In some implementations,the purchaser is the party that defines the roles and responsibilities.The roles 204 and responsibilities, can for example, be defined afterthe purchaser has decided on the items to include in the purchasetransaction 208.

In one implementation, the transaction engine 202 can receive a timeframe associated with each role 204. The time frame can include anamount of time that the party 206 is associated with the specific role204. The amount of time can be in the form of minutes, hours, days,weeks, years, etc. The amount of time can also be in the form of numberof transactions. For example, a party 206 can be assigned the role 204of approver for a day, month, or year. In another example, a party 206can be assigned the role 204 of recipient for one purchase transaction208.

In one implementation, the transaction engine 202 can receive a routingrule 210 associated with the purchase transaction 208. The routing rule210 can, for example, define how the purchase transaction 208 is routedamong the one or more parties 206. The routing rule 210 can define eachparty 206 and the role 204 of each party 206 as well as theresponsibility of each party 206 based on the role 204. The routing rule210 can, for example, specify which of the parties 206 receives thepurchase transaction 208 first. The routing rule 210 can also specifywhich of the parties 206 must approve the purchase transaction 208before the purchase transaction 208 can be processed for payment. Therouting rule 210 can also specify the party that is responsible forpaying for the purchase transaction 208.

In one implementation, the routing rule 210 can be received from any ofthe parties associated with the purchase transaction 208. For example,the routing rule 210 can be received from a buyer, or purchaser, of thepurchase transaction 208. For example, the party 206 that has to approvethe purchase transaction 208 before the purchase transaction 208 isprocessed can be the party 206 that determines how the other parties 206interact with the purchase transaction 208.

In one implementation, the transaction engine 202 can process thepurchase transaction 208 based on the role 204 of each of the parties206 and the routing rule 210. The transaction engine 202 can, forexample, send a shopping cart associated with the purchase transaction208 to the one or more parties 206 based on the specified role 204 ofeach party and the routing rule 210. For example, the routing rule 210can specify that a certain party 206 must receive the purchasetransaction 208 to enter credit card information to be able to pay forthe transaction 208 prior to the purchase transaction 208 beingprocessed for payment.

In one implementation, each of the parties 206 specified by the routingrule 210 can be required approve of the purchase transaction 208 priorto the purchase transaction 208 being processed. An approval can, forexample, include different forms. Approving the purchase transaction 208can depend on the role 204 of each party 206. An approval can, forexample, include setting a flag associated with the purchase transaction208.

In one implementation, the routing rule 210 can define a budget for thepurchase transaction 208. For example, the party 206 that defines therouting rule can define a budget that the purchase transaction 208cannot exceed. If the budget is exceeded by the purchase transaction208, then the routing rule 210 can require a party 206 to approve of thepurchase transaction 208 prior to the purchase transaction 208 beingprocessed for payment.

In one implementation, a group of buyers may purchase several itemstogether. In this case, one buyer can select some items or contributeportion of payments, or both. In this case, multiple parties may assumethe same role. For example, more than one party can be a buyer.

In one implementation, the routing rule 210 can define a category. Theapprover in this example has to approve of the purchase transactionunless the purchase transaction is associated with the category. Forexample, if the routing rule 210 is associated with the category“books,” if the purchase transaction does not include books, then theapprover must approve of the purchase transaction.

FIG. 3 shows a graphical conceptual flow diagram of an example processfor processing a purchase transaction. FIGS. 3A-3D show example screenshots associated with the conceptual flow diagram of FIG. 3. The processshows an example for user interaction with an on-line payment system,such as Google Checkout, involving purchasing a piece of jewelry from aweb site operated by a jewelry maker. The purchaser is purchasing theearrings for a friend as a gift, and needs the approval of her motherbefore purchasing the item because the mother is going to be paying forthe items. In general, the process and the screen shots illustrate thesteps a purchaser would take, and the screens the purchaser would see,when buying several pieces of jewelry in a transaction involvingmultiple parties. Of particular interest, the various components of anon-line payment system are visually integrated with the vendor's own website so the purchaser can see the progress of their shopping as they goalong, much as they would in an integrated purchasing environment, wherethe vendor itself takes care of payment processing.

Display 302 shows a general page from a vendor's web site. The display302, for a vendor called Garnish Jewelry, shows a number ofhigh-quality, handcrafted jewelry pieces (see FIG. 3A). Display 304shows a screen from the purchaser selecting one of the pieces ofjewelry—a pair or earrings with silver chains—from display 302. Generalweb page content is shown in the display 104, with navigational menucontrols in the form of selectable hyperlinks to the left, an image ofthe product for sale, a description of the product, and a price for theproduct (see FIG. 3B). In addition, display 304 shows a selectablecontrol in the form of an “add to cart” button 305 that a purchaser mayselect to purchase a unit of the product—here a pair of earrings.Selection of the button 305 may cause an HTTP request, in the form of anXMLHttpRequest (XHR), to be made of payment server 314, as indicated byArrow A.

The payment server 314 may then parse the HTTP request to obtain anidentifier for the purchaser, and also to identify the vendor andrelevant payment parameters. The identity of the purchaser may bedetermined, in one implementation, from a session ID. The purchaser maybe positively identified, for example, if the purchaser has previouslylogged into a system associated with the payment server 314 (such asthrough a general Google log in) or using a cookie. The purchaser mayalso be identified by their device without immediate identification ofthe purchaser, such as by a session ID that can later be associated witha user ID in the system when the purchaser logs in to the paymentprocessing system.

When the purchaser and vendor have been identified and the balance ofthe purchaser's shopping cart incremented, the changes may be passedback to the client device of the purchaser, as shown by Arrow B. Thetransmission of information may occur, for example, by XML transmissionformatted in a manner compatible with the code running on the clientdevice. As one example, the payment server may pass informationreflecting a description of the selected item(s), their quantity, theirprice, and a total price of goods in the purchaser's shopping cart.

Display 306 shows the result of a user's selection of button 305 (seeFIG. 3C). The purchaser may also choose to go to a checkout to pay orotherwise edit entries in his or her shopping cart, by selecting the“proceed to checkout” control button 318. Such a selection may finallytake the purchaser away from the vendor's underlying page, and to thepayment processor's page (although the checkout may also be performed inthe same content window of a browser as the vendor's web site, bymechanisms similar to those described above). This option is describedin more detail with respect to FIG. 3D.

At display 312, the user/purchaser has selected a “proceed to checkout”button, and is redirected to a web page operated by the payment server314. To generate this page, the payment server 314 may check itsdatabase fields that have been updated through the purchaser's selectionof “add to cart” buttons. At this point, the interaction with the usermay occur according to various mechanisms to permit closing out of thetransaction. For example, the user may be shown a list of items andtheir prices 322 that have been selected by the user. The user may thenselect items to delete or may increase or otherwise change thequantities of items. Such changes will be reflected in associateddatabases managed by the payment processor.

The user can also specify a routing rule 324. The user can select one ormore parties and the role associated with each party. For example, theuser can select Mary Smith as the receiver of the transaction and MarySmith, as the receiver, must approve of the earrings in the shoppingcart, and she can also provide the shipping address. The user can alsoselect Mother Tutone as the approver of the transaction and the approvermust pay for the transaction.

The shopping cart can then be routed to the other parties as specifiedin the routing rule 324. For example, the shopping cart can be sent, forexample, via email to the other parties according to the routing rule.Therefore, in this example, the shopping cart can be first sent to MarySmith. Mary Smith can, for example, receive a link to the purchasetransaction as an email. She can open up the link and be able to viewthe same display 312. As one of the other parties, she may be positivelyidentified, for example, if she had previously logged into a systemassociated with the payment server 314 or using a cookie. She may alsobe identified by the device without immediate identification of thepurchaser, such as by a session ID that can later be associated with auser ID in the system when the purchaser logs in to the paymentprocessing system.

She may be presented with the display 312 with an additional area thatallows her to perform her responsibility according to her role. In thisexample, she can be presented with an option of approving or decliningthe purchase of the earrings based on whether or not she likes theearrings. If she approves of the purchase, she can then provide theshipping address, and the shopping cart is then routed to the next partyMother Tutone. Mother Tutone can be identified in the same manner as theother parties. While reference is made to a serial process, one or moresteps of the process can be performed in parallel.

The user associated with paying for the transaction, in this example,Mother Tutone, may also be permitted to select a payment method, such asthrough a Google Checkout account or a debit or credit card or otherpayment mechanism 326. The payment server 314 may also store a preferredpayment method for the user and use that method (or present it as adefault) if the user does not select another. Finally, the user mayconfirm that the displayed information is accurate and may cause thetransaction to be completed by selecting checkout button 326.

When the person in charge of paying for the transaction chooses tocomplete the purchase, their account is debited by the payment server314 in an amount equal to the price of all the goods in the shoppingcart plus tax, shipping/handling, and other costs, such as a transactioncharge for the payment processor (assuming all other approvals have beenreceived). In a like manner, an account for the vendor may be credited,and the creditor may be notified of the transaction, with shippinginformation for the purchaser. The vendor may have previously selected apreferred method for being informed of transactions, such as by e-mailfor a small vendor and via XML messaging or updating of a database thatis accessible to the vendor (e.g., as stored in Google Base). Inaddition, the vendor and purchaser, in registering with the system, mayhave agreed to be contractually bound to make agreed-upon paymentsand/or deliveries of goods, so as to help ensure that transactions willbe carried out successfully. The vendor may receive information such asthe identity and quantity of goods sold, the amount of the transaction,and a shipping address for the purchaser so that the vendor can ship thegoods.

FIG. 4 is a flow diagram of an example process 400 for receivinginformation associated with a transaction. The process 400 can, forexample, be implemented in a system such as the transaction system 200of FIG. 2.

Stage 402 receives a role associated with one or more parties involvedwith a purchase transaction. For example, the transaction engine 202 canreceive a role associated with one or more parties involved with apurchase transaction.

Stage 404 receives a routing rule associated with the purchasetransaction, the routing rule defining how the purchase transaction isrouted among the one or more parties. For example, the transactionengine 102 can receive a routing rule associated with the purchasetransaction, the routing rule defining how the purchase transaction isrouted among the one or more parties.

Stage 406 processes the purchase transaction based on the role of eachparty and the routing rule. For example, the transaction engine 202 canprocess the purchase transaction based on the role of each party and therouting rule.

FIG. 5 is a flow diagram of an example process 500 for processing apurchase transaction. The process 500 can, for example, be implementedin a system such as the transaction system 200 of FIG. 2.

Stage 502 routes the purchase transaction to the one or more partiesbased on the role of each of the one or more parties and a routing rule.For example, the transaction engine 202 can route the purchasetransaction to the one or more parties based on the role of each of theone or more parties and the routing rule.

Stage 504 receives confirmation from the one or more parties to processthe purchase transaction. For example, the transaction engine 202 canreceive confirmation from the one or more parties to process thepurchase transaction.

FIG. 6 is a flow chart of another example process for receivinginformation associated with a purchase transaction. The process 600 can,for example, be implemented in a system such as the transaction system200 of FIG. 2.

Stage 602 identifies one or more parties associated with a purchasetransaction in a virtual shopping cart. For example, the transactionengine 202 can identify one or more parties associated with a purchasetransaction in a virtual shopping cart.

Stage 604 identifies one or more rules associated with the purchasetransaction and a role associated with each of the one or more parties.For example, the transaction engine 202 can identify one or more rulesassociated with the purchase transaction and a role associated with eachof the one or more parties.

Stage 606 determines whether to route the shopping cart to the one ormore parties based on the one or more rules and the role associated witheach of the one or more parties. For example, the transaction engine 202can determine whether to route the shopping cart to the one or moreparties based on the one or more rules and the role associated with eachof the one or more parties.

FIG. 7 is a flow chart of an example process for determining whether toroute a shopping cart. The process 700 can, for example, be implementedin a system such as the transaction system 200 of FIG. 2.

Stage 702 determines whether the one or more rules require any of one ormore parties to approve the purchase transaction in the virtual shoppingcart before the purchase transaction is processed. For example, thetransaction engine 202 can determine whether the one or more rulesrequire any of the one or more parties to approve the purchasetransaction in the virtual shopping cart before the purchase transactionis processed.

Stage 704 processes the virtual shopping cart based on thedetermination. For example, the transaction engine 202 can process thevirtual shopping cart based on the determination.

FIG. 8 shows an example of a generic computer device 800 and a genericmobile computer device 850, which may be used with the techniquesdescribed here. Computing device 800 is intended to represent variousforms of digital computers, such as laptops, desktops, workstations,personal digital assistants, servers, blade servers, mainframes, andother appropriate computers. Computing device 850 is intended torepresent various forms of mobile devices, such as personal digitalassistants, cellular telephones, smartphones, and other similarcomputing devices. The components shown here, their connections andrelationships, and their functions, are meant to be exemplary only, andare not meant to limit implementations of the inventions describedand/or claimed in this document.

Computing device 800 includes a processor 802, memory 804, a storagedevice 806, a high-speed interface 808 connecting to memory 804 andhigh-speed expansion ports 810, and a low speed interface 812 connectingto low speed bus 814 and storage device 806. Each of the components 802,804, 806, 808, 810, and 812, are interconnected using various busses,and may be mounted on a common motherboard or in other manners asappropriate. The processor 802 can process instructions for executionwithin the computing device 800, including instructions stored in thememory 804 or on the storage device 806 to display graphical informationfor a GUI on an external input/output device, such as display 816coupled to high speed interface 808. In other implementations, multipleprocessors and/or multiple buses may be used, as appropriate, along withmultiple memories and types of memory. Also, multiple computing devices800 may be connected, with each device providing portions of thenecessary operations (e.g., as a server bank, a group of blade servers,or a multi-processor system).

The memory 804 stores information within the computing device 800. Inone implementation, the memory 804 is a volatile memory unit or units.In another implementation, the memory 804 is a non-volatile memory unitor units. The memory 804 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 806 is capable of providing mass storage for thecomputing device 800. In one implementation, the storage device 806 maybe or contain a computer-readable medium, such as a floppy disk device,a hard disk device, an optical disk device, or a tape device, a flashmemory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. A computer program product can be tangibly embodied inan information carrier. The computer program product may also containinstructions that, when executed, perform one or more methods, such asthose described above. The information carrier is a computer- ormachine-readable medium, such as the memory 804, the storage device 806,memory on processor 802, or a propagated signal.

The high speed controller 808 manages bandwidth-intensive operations forthe computing device 800, while the low speed controller 812 manageslower bandwidth-intensive operations. Such allocation of functions isexemplary only. In one implementation, the high-speed controller 808 iscoupled to memory 804, display 816 (e.g., through a graphics processoror accelerator), and to high-speed expansion ports 810, which may acceptvarious expansion cards (not shown). In the implementation, low-speedcontroller 812 is coupled to storage device 806 and low-speed expansionport 814. The low-speed expansion port, which may include variouscommunication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet)may be coupled to one or more input/output devices, such as a keyboard,a pointing device, a scanner, or a networking device such as a switch orrouter, e.g., through a network adapter.

The computing device 800 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 820, or multiple times in a group of such servers. Itmay also be implemented as part of a rack server system 824. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 822. Alternatively, components from computing device 800 may becombined with other components in a mobile device (not shown), such asdevice 850. Each of such devices may contain one or more of computingdevice 800, 850, and an entire system may be made up of multiplecomputing devices 800, 850 communicating with each other.

Computing device 850 includes a processor 852, memory 864, aninput/output device such as a display 854, a communication interface866, and a transceiver 868, among other components. The device 850 mayalso be provided with a storage device, such as a microdrive or otherdevice, to provide additional storage. Each of the components 850, 852,864, 854, 866, and 868, are interconnected using various buses, andseveral of the components may be mounted on a common motherboard or inother manners as appropriate.

The processor 852 can execute instructions within the computing device850, including instructions stored in the memory 864. The processor maybe implemented as a chipset of chips that include separate and multipleanalog and digital processors. The processor may provide, for example,for coordination of the other components of the device 850, such ascontrol of user interfaces, applications run by device 850, and wirelesscommunication by device 850.

Processor 852 may communicate with a user through control interface 858and display interface 856 coupled to a display 854. The display 854 maybe, for example, a TFT (Thin-Film-Transistor Liquid Crystal Display)display or an OLED (Organic Light Emitting Diode) display, or otherappropriate display technology. The display interface 856 may compriseappropriate circuitry for driving the display 854 to present graphicaland other information to a user. The control interface 858 may receivecommands from a user and convert them for submission to the processor852. In addition, an external interface 862 may be provide incommunication with processor 852, so as to enable near areacommunication of device 850 with other devices. External interface 862may provide, for example, for wired communication in someimplementations, or for wireless communication in other implementations,and multiple interfaces may also be used.

The memory 864 stores information within the computing device 850. Thememory 864 can be implemented as one or more of a computer-readablemedium or media, a volatile memory unit or units, or a non-volatilememory unit or units. Expansion memory 874 may also be provided andconnected to device 850 through expansion interface 872, which mayinclude, for example, a SIMM (Single In Line Memory Module) cardinterface. Such expansion memory 874 may provide extra storage space fordevice 850, or may also store applications or other information fordevice 850. Specifically, expansion memory 874 may include instructionsto carry out or supplement the processes described above, and mayinclude secure information also. Thus, for example, expansion memory 874may be provide as a security module for device 850, and may beprogrammed with instructions that permit secure use of device 850. Inaddition, secure applications may be provided via the SIMM cards, alongwith additional information, such as placing identifying information onthe SIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory,as discussed below. In one implementation, a computer program product istangibly embodied in an information carrier. The computer programproduct contains instructions that, when executed, perform one or moremethods, such as those described above. The information carrier is acomputer- or machine-readable medium, such as the memory 864, expansionmemory 874, memory on processor 852, or a propagated signal that may bereceived, for example, over transceiver 868 or external interface 862.

Device 850 may communicate wirelessly through communication interface866, which may include digital signal processing circuitry wherenecessary. Communication interface 866 may provide for communicationsunder various modes or protocols, such as GSM voice calls, SMS, EMS, orMMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, or GPRS, among others.Such communication may occur, for example, through radio-frequencytransceiver 868. In addition, short-range communication may occur, suchas using a Bluetooth, WiFi, or other such transceiver (not shown). Inaddition, GPS (Global Positioning System) receiver module 870 mayprovide additional navigation- and location-related wireless data todevice 850, which may be used as appropriate by applications running ondevice 850.

Device 850 may also communicate audibly using audio codec 860, which mayreceive spoken information from a user and convert it to usable digitalinformation. Audio codec 860 may likewise generate audible sound for auser, such as through a speaker, e.g., in a handset of device 850. Suchsound may include sound from voice telephone calls, may include recordedsound (e.g., voice messages, music files, etc.) and may also includesound generated by applications operating on device 850.

The computing device 850 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as acellular telephone 980. It may also be implemented as part of asmartphone 982, personal digital assistant, or other similar mobiledevice.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), and theInternet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made. For example, variousforms of the flows shown above may be used, with steps re-ordered,added, or removed. Also, although several applications of the paymentsystems and methods have been described, it should be recognized thatnumerous other applications are contemplated. Moreover, although many ofthe embodiments have been described in relation to a so-called shoppingcart, that term should be understood to include various forms ofmechanisms for presenting an organized grouping of items or servers thata user has selected for possible purchase, and can include suchdescriptions as shopping baskets and the like. Accordingly, otherembodiments are within the scope of the following claims.

1-20. (canceled)
 21. A computer-implemented method for processingmulti-party transactions, comprising: receiving, by one or morecomputing devices, one or more rules associated with a purchasetransaction, the one or more rules defining how the purchase transactionis routed among one or more parties involved with the purchasetransaction; receiving, by the one or more computing devices, anindication to proceed to checkout from a first party of the one or moreparties of the one or more parties involved with the purchasetransaction, wherein the indication to proceed to checkout comprises arequest to complete the purchase transaction; in response to the one ormore rules associated with the purchase transaction, transmitting, bythe one or more computing devices, a payment request to a second partyof the one or more parties involved with the purchase transaction,wherein the payment request comprises a request that the second party ofthe one or more parties approves the purchase transaction; receiving, bythe one or more computing devices, a payment authorization, wherein thepayment authorization comprises an approval of the purchase transactionfrom the second party of the one or more parties; and completing, by theone or more computing device, the purchase transaction.
 22. Thecomputer-implemented method of claim 21, wherein the role of the firstparty of the one or more parties of the one or more parties is one ormore of a buyer and a suggestor.
 23. The computer-implemented method ofclaim 21, wherein the roles associated with the purchase transactiondefine a responsibility of each party of the one or more parties of theone or more parties for approving the purchase transaction.
 24. Thecomputer-implemented method of claim 21, further comprising: in responseto the one or more rules associated with the purchase transaction,transmitting, by the one or more computing devices, a second paymentrequest to a third party of the one or more parties of the one or moreparties involved with the purchase transaction, wherein the secondpayment request comprises a request that the third party of the one ormore parties of the one or more parties approves the purchasetransaction; and receiving, by the one or more computing devices, asecond payment authorization, wherein the second payment authorizationcomprises a second approval of the purchase transaction from the thirdparty of the one or more parties.
 25. The computer-implemented method ofclaim 24, wherein the first payment request further comprises a firstpartial amount of the purchase transaction and first payment accountinformation and the second payment request further comprises a secondpartial amount of the purchase transaction and second payment accountinformation.
 26. The computer-implemented method of claim 21, whereinthe second party of the one or more parties approves the purchasetransaction if a spending limit is not exceeded by the purchasetransaction.
 27. The computer-implemented method of claim 21, whereinthe payment request is transmitted to the second party of the one ormore parties involved with the purchase transaction based on a ruleassociated with the purchase transaction specifying that the secondparty of the one or more parties is responsible for paying for thepurchase transaction.
 28. The computer-implemented method of claim 21,wherein the payment request further comprises an amount of the purchasetransaction and payment account information.
 29. A system for processingmulti-party transactions, the system comprising: a storage medium; and aprocessor communicatively coupled to the storage medium, wherein theprocessor executes application code instructions that are stored in thestorage medium and that case the system to: receive one or more rulesassociated with the purchase transaction, the one or more rules defininghow the purchase transaction is routed among one or more partiesinvolved with the purchase transaction; receive an indication to proceedto checkout from a first party of the one or more parties involved withthe purchase transaction, wherein the indication to proceed to checkoutcomprises a request to complete the purchase transaction; in response tothe one or more rules associated with the purchase transaction, transmita request to a second party of the one or more parties involved with thepurchase transaction; receive an authorization, wherein theauthorization comprises an approval of the purchase transaction from thesecond party of the one or more parties; and complete the purchasetransaction.
 30. The system of claim 29, wherein the roles associatedwith the purchase transaction define a responsibility of each party ofthe one or more parties for approving the purchase transaction.
 31. Thesystem of claim 29, wherein the processor is further configured toexecute computer-executable instructions stored in the storage medium tocause the system to: in response to the one or more rules associatedwith the purchase transaction, transmit a second request to a thirdparty of the one or more parties involved with the purchase transaction;and receive a second authorization, wherein the second authorizationcomprises a second approval of the purchase transaction from the thirdparty of the one or more parties.
 32. The system of claim 31, whereinthe first request comprises a first indication of a first partial amountof the purchase transaction and first payment account information andthe second request comprises a second indication of a second partialamount of the purchase transaction and second payment accountinformation.
 33. The system of claim 29, wherein the second party of theone or more parties approves the purchase transaction if a spendinglimit is not exceeded by the purchase transaction.
 34. The system ofclaim 29, wherein the request comprises an amount of the purchasetransaction and payment account information.
 35. The system of claim 29,wherein the request is transmitted to the second party of the one ormore parties involved with the purchase transaction based on a ruleassociated with the purchase transaction specifying that the secondparty of the one or more parties is responsible for paying for thepurchase transaction.
 36. A computer program product, comprising: anon-transitory computer-readable medium having computer-readable programinstructions embodied therein that when executed by a computer cause thecomputer to process multi-party transactions, the computer-readableprogram instructions comprising: computer-readable program instructionsfor receiving one or more rules associated with the purchasetransaction, the one or more rules defining how the purchase transactionis routed among one or more parties involved with the purchasetransaction; computer-readable program instructions for receiving anindication to proceed to checkout from a first party of the one or moreparties involved with the purchase transaction; in response to the oneor more rules associated with the purchase transaction,computer-readable program instructions for transmitting a request to asecond party of the one or more parties involved with the purchasetransaction; and computer-readable program instructions for receiving anauthorization, wherein the authorization comprises an approval of thepurchase transaction from the second party of the one or more parties.37. The computer program product of claim 36, wherein the rolesassociated with the purchase transaction define a responsibility of eachparty of the one or more parties for approving the purchase transaction.38. The computer program product of claim 36, further comprising: inresponse to the one or more rules associated with the purchasetransaction, computer-readable program instructions for transmitting asecond request to a third party of the one or more parties involved withthe purchase transaction; and computer-readable program instructions forreceiving a second payment authorization, wherein the secondauthorization comprises a second approval of the purchase transactionfrom the third party of the one or more parties.
 39. The computerprogram product of claim 38, wherein the first request comprises a firstindication of a first partial amount of the purchase transaction andfirst payment account information and the second request comprises asecond indication of a second partial amount of the purchase transactionand second payment account information.
 40. The computer program productof claim 36, wherein the second party of the one or more partiesapproves the purchase transaction if a spending limit is not exceeded bythe purchase transaction.
 41. The computer program product of claim 36,wherein the request comprises an amount of the purchase transaction andpayment account information.
 42. The computer program product of claim36, wherein the request is transmitted to the second party of the one ormore parties involved with the purchase transaction based on a ruleassociated with the purchase transaction specifying that the secondparty of the one or more parties is responsible for paying for thepurchase transaction.